ci: extend installer testing - #260
Conversation
357b60f to
34666d0
Compare
| # Install from the release that was just published, the way the README tells users to. | ||
| # This is the only check that reaches the installer through its published asset URL, and | ||
| # the only one that runs against the artifacts of this release rather than the previous one. | ||
| smoke: |
There was a problem hiding this comment.
I would run this as a separate workflow entirely (I'd literally just call it smoke.yml), triggered when a release is published (not when created as a draft, but when it is published from draft), and maybe when the manifest gets published as well.
Running this as part of the release workflow means that the whole workflow will be considered failed if this smoke job fails for any reason (even spurious ones), however the reality is that by the point it runs, the release itself succeeded and was published both to crates.io, and to GitHub (the draft release is published and made immutable). At that point, any issues with the released artifacts will require a new release to address - basically, it isn't actionable at that point.
Using a separate workflow means we can run it not only upon releases being published without interfering with the release workflow itself; but when the manifest changes as well, and run a broader set of smoke tests that way.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
06be6e2 to
a2595df
Compare
3 participants
Closes #255.
This PR includes changes to:
installer.shas a release assetinstaller.ymlon changes torelease.ymlinstaller.ymltesting all the opt-out flags (this was not being tested and cargo fallback was broken)bin/installer.sh, which read$0(the script path) instead of$1(the requested version)smokejob torelease.ymlthat downloads the installer script from the just published release and installs that release with it